home *** CD-ROM | disk | FTP | other *** search
/ NetNews Offline 2 / NetNews Offline Volume 2.iso / news / comp / std / c / 25 < prev    next >
Text File  |  1996-08-06  |  2KB  |  45 lines
  1. Newsgroups: comp.std.c
  2. Path: newsfeed.internetmci.com!ncar!uchinews!news
  3. From: Michael Spertus<mps@geodesic.com>
  4. Subject: Re: Alignment of malloc()
  5. X-Nntp-Posting-Host: ford.uchicago.edu
  6. Message-ID: <DKo8ns.8A9@midway.uchicago.edu>
  7. Sender: news@midway.uchicago.edu (News Administrator)
  8. Organization: Dept. of Mathematics
  9. References: <DKDA7D.Kw7@midway.uchicago.edu> <j66Sx*FRe@yaps.rhein.de> <DKKHCH.L6r@midway.uchicago.edu> <4ccbdb$5v6@fg70.rz.uni-karlsruhe.de>
  10. Date: Thu, 4 Jan 1996 19:26:16 GMT
  11.  
  12. In article <4ccbdb$5v6@fg70.rz.uni-karlsruhe.de>,
  13. Thomas Koenig <ig25@mvmap66.ciw.uni-karlsruhe.de> wrote:
  14. >
  15. >I know of no compiler which is as brain-damaged as the one you describe;
  16. >when I encounter one, I'd tend to howl to the vendor.
  17. >-- 
  18. Many PC compilers have this problem (See the BYTEmark column in the
  19. December BYTE). The problem is that Win32 GlobalAlloc(), which is
  20. what most allocators use to get their arenas, returns a 32-bit aligned
  21. pointer. Most standard library implementations will pass through this
  22. alignment (probably because the implementor does not realize that
  23. GlobalAlloc() does not align very well so that code for an sbrk()
  24. based allocator cannot be used without change. They may also be unaware
  25. that Pentium PCs use 64 bits data buses). This problem is magnified
  26. because the Pentium (apparently) drops into microcode on nonaligned
  27. loads, so that nonaligned floating point benchmarks are over 300%
  28. slower.
  29.  
  30. Therefore, any code using floats must align all floating point malloc()
  31. to avoid running with abysmal efficiency on many of the most popular
  32. C/C++ compilers. I would like to believe that there should be an
  33. expectation that "malloc(float)" is a suitable or proper way to
  34. portably allocate a float ("suitable" and "proper" are the words used
  35. in the standard and reference documents to describe how malloc() should
  36. be aligned).
  37.  
  38. In today's practice, I cannot do that. Hopefully, the BYTE article and
  39. maybe this thread will alert compiler vendors whose implementations
  40. don't align malloc() on float boundaries that their implementation is
  41. brain-damaged (your words) or not in the spirit of the standard (mine)
  42. and cause them to change their implementations. Until then, there is
  43. no way to write portable code that can be counted on to perform the
  44. simplest floating point operations without gross performance penalties.
  45.